Often, a computer in a distributed system receives messages when certain events occur in other computers in the system. These messages are called notifications. In order to register interest in certain events, a subscriber computing device (called a subscriber or subscriber device) sends a subscription request that describes the events of interest to event source computing devices (called an event source or event source device) in the system. Subsequently, the subscriber device will receive notifications from the event source device when the events of interest occur.
Notifications are different from regular response messages. A regular response message is always a solicited message because a client can only receive a response message after it has sent a request message. On the contrary, a subscriber device can receive unsolicited notifications (similarly to electronic mail (email) spam).
Unsolicited notifications pose a problem to the systems that use subscription/notification message pattern because unsolicited notifications can irritate system users, corrupt system state, or even realize denial of service attack. Thus, it is desirable to have a mechanism to filter unsolicited notifications instead of processing them.
One approach of filtering unsolicited notifications is for a subscriber device to maintain a list of valid event source devices' Internet protocol (IP) addresses. When a notification is received, the subscriber device can check if the event source device's IP is contained in the valid IP list. If the event source device's IP address is contained in the valid IP list, the notifications will be accepted. Otherwise, the notification will be rejected. There are several problems with this approach:                If IP address is faked, the filtering logic will fail to identify unsolicited notifications.        If a valid notification is sent from a different machine, the filtering logic will reject a valid notification.        It may not be practical or possible to maintain a list of valid event source devices' IP addresses. Even if the list will be populated by IP addresses of the machines accepting subscription messages, the list may not be accurate because notifications may be sent not by the same machine that accepted the corresponding subscriptions.        
Another approach to filtering unsolicited notifications is for a subscriber device to filter notifications based on their content. For example, most email spam filters are content-based. There are several problems with this approach:                Developing content-based notification filtering system is complex and expensive.        Content-based notification system is slow since it has to parse the whole notification to make a decision whether to accept or reject the notification.        Content-based notification systems are not accurate, i.e., invalid notifications are often not correctly recognized.        Content-based notification system should be properly configured to be effective.        
Yet another approach to filtering unsolicited notifications is for a subscriber device to maintain a list of valid correlation identifiers (IDs). When a notification is received, the subscriber device can check if the correlation ID in the notification is contained in the list of valid correlation IDs. If the correlation ID is contained in the list, the notification will be accepted. The notification will be rejected otherwise. There are several problems with this approach:                Checking whether the list of valid correlation IDs contains the correlation ID received in the notification can be very expensive especially if the list is stored in the database, which is usually the case. The slow verification mechanism could be exploited by denial of service attack.        Usually, correlation ID generation logic is quite simple (for example: 1, 2, 3 . . . ). Thus, a randomly chosen correlation ID would have a non-negligible chance of succeeding.        
Thus, there is a need for a better approach to filtering unsolicited notifications.